image

Mozilla meldt incident met private keys certificaatautoriteit eMudhra

dinsdag 20 oktober 2026, 15:29 door Redactie, 5 reacties

Mozilla waarschuwt internetgebruikers voor een beveiligingsincident bij de Indiase certificaatautoriteit eMudhra, waarbij de private keys van acht eMudhra intermediate certificaten zijn gecompromitteerd. Met deze keys kunnen aanvallers voor allerlei websites die niet van hen zijn certificaten uitgeven die voor phishing en man-in-the-middle (MiTM)-aanvallen zijn te gebruiken. Met de frauduleus uitgegeven certificaten zou een aanvaller het verkeer van en naar websites kunnen lezen en aanpassen.

Mozilla ontving afgelopen zaterdag de eerste melding van de gecompromitteerde keys en heeft de betreffende certificaten inmiddels via een update voor OneCRL geblokkeerd. Dit is een mechanisme binnen Firefox waarmee Mozilla certificaten kan intrekken, zodat die niet meer door de browser worden vertrouwd. Daarnaast zijn er vandaag updates voor Firefox uitgebracht om gebruikers te beschermen die vanwege aangepaste instellingen de OneCRL-update niet hebben ontvangen.

Via intermediate certificaten zijn voor allerlei domeinen tls-certificaten uit te geven, die worden gebruikt voor de identificatie van websites en het versleutelen van verkeer. Mozilla zal het rootcertificaat waarmee de getroffen intermediate certificaten zijn gesigneerd van de NSS-lijst met vertrouwde certificaten halen. Hoe de keys van eMudhra konden worden gecompromitteerd is nog niet bekend. Mozilla zegt als het kan binnenkort met meer informatie te zullen komen.

Reacties (5)
20-10-2026, 17:31 door Anoniem
Volgens een reactie op Hacker News zouden de sleutels in een publiek toegankelijke map op de server van eMudhra hebben gestaan. Als dat klopt, is het volstrekt krankzinnig dat ze niet in een HSM waren opgeslagen en beheerd. Dit is mogelijk nog erger dan de DigiNotar-affaire.

https://news.ycombinator.com/item?id=50167508
20-10-2026, 21:26 door Erik van Straten
Het risico hiervan voor Nederlanders valt m.i. erg mee; dat is anders voor inwoners van landen met ernstig dictatoriale regimes.

De reden hiervoor is dat een aanvaller tussen een webbrowser en de echte website moet "gaan zitten". Dat kan op verschillende manieren:

• Door manipulatie van netwerkapparatuur op de route tussen de webbrowser en de echte server. Denk aan gehackte of fake public WiFi routers (evil twin), maar ook (vooral bij dictatoriale regimes) in rekencentra van ISP's of op landelijk niveau;

• Door manipulatie van DNS-verkeer.

Een m.i. veel groter risico dan bij het kopiejatten van private keys passend bij (root-, internediate- of leaf) certificaten bestaat bij ofwel BGP-hijacks ofwel bij dusdanige DNS-manipulatie dat zowel (Domain Validated) certificaatuitgevers als browser-gebruikers naar nepwebsite(s) worden gestuurd. "Dankzij" de normalisatie van 1FA DV-certificaten.
21-10-2026, 20:49 door Anoniem
Door Erik van Straten:

(ziet weinig risico in NL voor compromised root CAs )

Een m.i. veel groter risico dan bij het kopiejatten van private keys passend bij (root-, internediate- of leaf) certificaten bestaat bij ofwel BGP-hijacks ofwel bij dusdanige DNS-manipulatie dat zowel (Domain Validated) certificaatuitgevers als browser-gebruikers naar nepwebsite(s) worden gestuurd. "Dankzij" de normalisatie van 1FA DV-certificaten.

Ik snap werkelijk niet waarom je dat denkt .

Met de private key van een trusted root/intermediate kun je werkelijk vrijwel _iedere_ site (of : code, sommige intermediates waren code-signers) nagenoeg onmerkbaar spoofen .
En voor relatief lange tijd.

(vrijwel : sommige applicaties doen aan certificate pinning - controleren dat de signer of certificaat zelf is wie ze verwachten. Stuxnet werd zo ontdekt omdat Chrome dit controleerde voor de google suite . )

In het stuk dat ik wegknipte stel je eerst dat je MITM moet worden om er iets mee te doen door bijvoorveeld een DNS of BGP aanval - en zie je dat blijkbaar als relatief lastig .
En vlak daarna wil je je stokpaarde bespringen en roep je hoe erg domain validated certificaten zijn vanwege het risico op dns of bgp hijacks - waarin een derde partij (erg zichtbaar) voor een enkele site een certificaat aanvraagt en gebruikt . SURE DUDE .
21-10-2026, 22:18 door Erik van Straten - Bijgewerkt: 21-10-2026, 22:20
Door Anoniem:
Door Erik van Straten:

(ziet weinig risico in NL voor compromised root CAs )

Een m.i. veel groter risico dan bij het kopiejatten van private keys passend bij (root-, internediate- of leaf) certificaten bestaat bij ofwel BGP-hijacks ofwel bij dusdanige DNS-manipulatie dat zowel (Domain Validated) certificaatuitgevers als browser-gebruikers naar nepwebsite(s) worden gestuurd. "Dankzij" de normalisatie van 1FA DV-certificaten.

Ik snap werkelijk niet waarom je dat denkt .

Met de private key van een trusted root/intermediate kun je werkelijk vrijwel _iedere_ site (of : code, sommige intermediates waren code-signers) nagenoeg onmerkbaar spoofen .
En voor relatief lange tijd.

(vrijwel : sommige applicaties doen aan certificate pinning - controleren dat de signer of certificaat zelf is wie ze verwachten. Stuxnet werd zo ontdekt omdat Chrome dit controleerde voor de google suite . )
Certificate Pinning is kanslozer met de steeds kortere levensduur van certificaten.

Wat wel helpt is CAA (https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization).

Door Anoniem: In het stuk dat ik wegknipte stel je eerst dat je MITM moet worden om er iets mee te doen door bijvoorveeld een DNS of BGP aanval - en zie je dat blijkbaar als relatief lastig .
Niet alleen ik, ook Mozilla (https://lwn.net/Articles/1101643/):
An attacker who could intercept a user's connection could use those certificates to impersonate websites and potentially read or modify traffic.

En Dan Goodin (https://arstechnica.com/security/2026/10/the-internet-goes-on-high-alert-after-discovery-of-8-compromised-tls-certs/):
One caveat: exploiting compromised certificates requires an active adversary-in-the-middle attack, meaning the attacker must act as a proxy between two TLS parties and receive encrypted traffic, decrypt it, reencrypt it, and send it to the other party. Such capabilities, in some cases, are usually limited to only the most well-resourced attackers. People with control of a local network—at a coffee shop, university, or other organization—face much less of a challenge.

Grootschalige aanvallen zijn alleen mogelijk als cybercriminelen (of foute overheden) toegang hebben tot "de backbone" van internet in een land (op bijv. ISP-niveau) of knooppunten tussen meerdere landen (denk in NL aan AmsIX). Bovendien zijn de meeste browsers ondertussen geüpdated met blocklists van de betrokken certificaten.

Public WiFi (met evil twin of gehackte netwerkapparatuur) is ook een risico, maar denkbare aanvallen zijn in de meeste gevallen kleinschalig. Maar omdat de meeste browsers standaard niet waarschuwen voor http zijn daar, ook zonder onterecht uitgegeven certificaten, hijacks van verbindingen eenvoudig mogelijk - zonder dat de browser-gebruiker gewaarschuwd wordt.

Door Anoniem: En vlak daarna wil je je stokpaarde bespringen en roep je hoe erg domain validated certificaten zijn vanwege het risico op dns of bgp hijacks - waarin een derde partij (erg zichtbaar) voor een enkele site een certificaat aanvraagt en gebruikt . SURE DUDE .
Dat kan voor een enkele site maar ook meerdere (https://www.theregister.com/security/2026/10/07/attackers-hijacked-top-level-domains-minted-fake-security-certs-for-google-and-other-orgs/5301718).

Voorbeelden van BGP hijacks: https://www.kentik.com/blog/bgp-hijacks-targeting-cryptocurrency-services/ en https://www.certik.com/blog/bgp-hijacking-the-usd1-9m-klayswap-attack-through-manipulated-network-flow. Zelf heb ik ooit een heel stel BGP hijacks op https://infosec.exchange beschreven (incl. eigen onderzoek) maar helaas staan die toots niet meer online (ik moet die tekst nog wel ergens hebben maar ik heb nu geen zin om te zoeken).

Maar sowieso kijken mensen niet goed naar domeinnamen in de adresbalk van hun browser (zie bijv. de nep Roblox sites die ik beschrijf onderin https://todon.nl/@ErikvanStraten/117389256050839674 en de volstrekt onzinnige domeinnamen gebruikt voor de recente Whatsapp scam, onderdeel van een draad: https://todon.nl/@ErikvanStraten/117468804351650112).
23-10-2026, 11:36 door Erik van Straten
En toen werd het stil.

Onbegrijpelijk vind ik het dat Anoniem, zonder steekhoudende argumenten, mijn eerste reactie hierboven bekritiseert en niet meer reageert nadat ik mijn eerdere reactie verder onderbouw.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.